Hi guys, I was a little disappointed with the performance from the MPGsmooth.c program. It worked, but depending on how i set the smoothing factor i would either have to live with fairly rough motion when on 0.010" increments, or movement that dragged on forever until eventually the time limit finished the movement with a jolt at the end. 

I modified the program to start with a high smoothing factor (TAU) and then decrease the value based on the "no change" time, so that its very smooth at first and still finishes up motion in a reasonable amount of time. The starting value, minimum value and rate of change are all easily adjustable in the program. Seems to be working very well for me so far. I also took it a step further and set it up to modify axis acceleration during mpg movement and set it back to normal when finished. These lines are ignored with comments in the file in case it might get confusing, but they are there if you feel like setting up acceleration numbers too. A value of about half seemed to work well for me, if you go too low it can do some odd motions when reversing.

Anyway i thought I would share my program with you guys. Takes a little while to tune it, but it can provide much better performance then all the mpg programs included with kmotioncnc. One last thing, im not a C programmer, didnt know a thing a few months ago, so it may not be perfect, but it does work well. Hope it helps someone.

Mark

mpgsmoother.c-14037.txt

Thanks for sharing this.

BTW I did receive the .c attachment as an email, but then Yahoo deleted it on the Web Interface.  It is probably best to rename .c files as .txt files so Yahoo treats it better.

Regards

TK

 

Sorry, yeah looks like its missing. Im pretty sure it was there. I tried renaming to TXT file this time. If this still doesnt work the file is available on the cnczone forum.

 

I think it would be simpler and better to always call the CheckDistToStop functions in the loop regardless of what the MPG is doing.  KMotionCNC may not stop all other motion commands such as what might be commanded through MCode Programs (ie probing, homing, tool changes, etc...). 

Regards

TK

 

I solved another issue I had with my machine today and the soloution should probably be added to this program. Occasionally it would shoot right on past the soft limit when turning the mpg, this problem was actually more noticeable since i modifed the mpgsmooth program, but it was still there occasionally before. I was running the adjustsoftlimitstest.c program in a different thread based on toms advice and it was working fine most times but would occasionally not work at all and go past soft limit.

So instead of running adjustsoftlimitstest.c and checking distance to stop continuously in a forever loop, i included adjustsoftlimits.c in my init file and added the check distance to stop right after each command to move by the mpg. Seems to have fixed the problem. I ran into a soft limit maybe 50-60 times tonight as a test and not a single problem so it appears like i have it fixed. 

Here is the program with Toms adjustment and also adjustsoftlimits built in. This only checks soft limits for MPG movement, but I believe KmotionCNC will stop it for all other conditions. Can you confirm this Tom?

If you hit the Stop Button that would stop the Thread from executing.  If you didn't re-execute the Thread on the next initialization then the Thread would not be running and there would be no protection.  Or if you inadvertently executed some other Program in the Thread it would also kill the execution.

Did you notice if the Thread had a Green Bar indicating that it was still running when you were able to go past the limit?

Regards

TK

 

Any possible idea why it was occasionally going past the soft limit for me?

Could it be related to the fact that i was running adjustsoftlimitstest in another thread?

Yes.  We see some incorrect behavior with standard fixed Soft Limits and the MPG Program.  We'll need some time to investigate.  Theanks for the good description.

Regards

TK

 

It appeared to be running, and doing its job, but occasionally doing nothing. It was running for sure actually because it would stop in the right place without overshooting at all, and then randomly it would just coast way past the soft limit, like an inch past it. 

I actually did some testing yesterday with adjustsoftlimits completely removed, and only my init thread running and the problem existed even then. It would stop at soft limit most all the time, with a slight overshoot based on speed which is expected. But every now and then (maybe 1 in 10 times or less) it would go way past it (like an inch) and just coast slowly to a stop. As if a feedhold was never applied at all. Very strange.

Since including adjustsoftlimits in my init again and checking distance to stop immediately after the mpg move commands it appears to be working perfectly.